Module 11 Closure
Spring 2006
Prepared by Greg Kinney

Most meaningful items

• The most meaningful in this module was to learn how to set up a monitoring system and the part about meetings.

• Earned value analysis 10.3 was laid out very well. The author explained the math well, then backed it up with some graphs illustrating the concept. Now if I can just remember all the acronyms.

• A few estimating percent completion aids where presented. One I recognized and have seen used. The others seem useable but might be a little tough to explain to different levels of management.

• The clearest part of this module for me was the explanation and examples regarding earned value and project performance criteria.  I thought the graph on page 509 and the equations on pages 510-511 were extremely helpful in understanding the variance factors in relation to project performance.  The CPI (Cost Performance Index) and the SPI (Schedule Performance Index) are also helpful indicators for quickly evaluating/assessing the performance on a project.  The five questions at the end of the chapter appeared to be overwhelming until I really understood the previously mentioned pages.  The problems actually helped me to solidify the principles and the calculations involved in coming up with values for the variance.

• This chapter stresses the importance of communication between key project team members and top management using reporting. Reporting must contain only the information the receiver needs and must be accurate and timely. Meetings are an excellent source of communication, providing project data including status of project tasks, resource use, and responsibility of assigned items.

• Clearest thing: The theory of earned value analysis is pretty clear. Definitions are logical and results easy to read once all variances and indices are understood.

• I enjoyed the discussion on the closed-loop cycle of planning-monitoring-and controlling.   It was interesting to look at some processes that we have in place, that are a daily, mundane chore and see them as a method of monitoring and controlling.  Well, more of a system to C.Y.A and sound the alarm if something starts to go wrong.

• Comment:  The ‘muddiest’ in this module was to understand the different measurements to do earned value analysis. 

• Comment:  By far the most unclear and the only unclear thing in this chapter is the question about the Jackson Insurance and Title Co. This chapter explained the use of planning, monitoring, control and reporting processes—never quality assurance. I’ll do my best to help out the group; they all seem to do very well at these discussion problems. As far as my question I’ll refer to your answer in the group module 11.  Maybe I’m reading into this problem wrong and I’ll pick it up in group discussion. 

• Comment:  The least clear item would have to be diving into the variances and indices.  Trying to stuff all your trade offs and budget delays and accelerations into an equation, coming out with a number and then have that make intuitive sense seems like something that would have to come from OJT, and a supervisor that insisted on them.  

• Comment:  The most meaningful item in the module was the development of a monitoring system. There are details that will help set one up. However, what is too much information? I understand that some information may not be necessary for a PM to monitor at specific times during the project and that too much may make it difficult to assimilate the data. But, is it not true that more information a PM has the better the PM can control the project (isn’t there a saying that goes somewhat like this, “there is never enough information”). 

Instructor’s reply:  Yes, people say there’s never enough information.  But they also say there’s too much information.  Both are true.  There’s always a deficit of the meaningful and specific information needed to move forward on an issue or item in front of you at the moment.  The process of generating either accurate information, or at least acceptable guesses, is work, and it’s what we’re paid to do. 

There is also a mountain of information that for our purposes does not have value.  Most of it is data.  Data can’t even be called information until it is filtered and processed into something that has meaning.  And information isn’t useful to us unless it is or can become relevant to the problems we’re working on.

In monitoring projects, you don’t want to do what Ma Bell did (see the anecdote in the book).  There is no point in collecting statistics in the way they did, and it’s wasteful, even though it’s true that much of that information might be useful in time.  (If you wanted to do a simulation on processes involving that data, such huge samples over a long period of time would be a gold mine.  But you could do the same thing more cost effectively through smaller samples when needed.)

When I was starting out as a construction engineer, I was given some good advice to the effect that you want to be able to capture costs and productivity accurately – but if it gets to the point that you have one guy with a clipboard following around every guy doing work just to monitor his progress, you know you’ve gone too far.  There’s no solid answer to the question you raised about how much information to collect – i.e., how granular it should be.  The only thing we can say for sure is we need to make sure that there is enough information to enable us to monitor those project metrics that need monitoring in an acceptably cost-effective manner. 

So you do need information on cost and performance, which you can get from rolling up daily reports in some kinds of work.  But you also need to keep tabs on some risk related items that you have predetermined require monitoring.  The specific risks you monitor should be selected in advance and adjusted as you go along, based on the probability that they would occur, and the impact they would have if they did.

• Comment:  The muddiest part of this module had to do with the relationship between planning-monitoring and controlling.  I came into this module with a notion of that relationship and I left the module with that same notion.  I think some detailed examples showing it done correctly and a detailed example showing it done incorrectly would have given me a better perspective on the topics.  There was plenty of detail for each topic; especially the reporting and information portions.  But the topics were never tied together real well in my opinion (it was brief at best).  Nevertheless, the module was an extension of project management and the topic of ‘project control’ will be touched upon in the next chapter as noted in module eleven.

• Comment:  Page 518 shows milestone reporting using a simple project network diagram. I am most familiar with earned value analysis in spreadsheet form. What software generates a milestone report and how can they be implemented?  

Instructor’s reply:  Great question, but I have to admit I’m stumped.  My experience is limited to Excel and Microsoft Project, and you could create such reports in Excel, of course.  What I think may have promise is a higher-end software package like Primavera’s P3.   This is reported to have capabilities of producing numerous custom reports.  But I don’t have first hand knowledge of this. 

• Comment:  Muddiest thing: The conventions used to estimate percent completion (p. 508+). Which is appropriate in which case and why not use a percent completion from what we believe is appropriate? 

Instructor’s reply:  You will find that the practice of giving an estimated % complete is almost universal.  Nonetheless, the text authors and other project management experts criticize this practice.  The estimates you give your boss are subjective, rarely grounded in a detailed understanding of what remains, and consequently of little or no value.  This stuff is then trotted out and reported as accurate in one-liner descriptions of project status. 

What makes it worse is that these kinds of estimates are applied to projects as a whole, which is worse than applying it to specific tasks within projects.

To combat this deplorable state of affairs, the authors propose several different rules applicable to project tasks.  The closes to the common practice of estimated % complete is the proportionality rule (p. 509), also called “level of effort” (LOE) in PMBOK.  There you just assume linear progress for a given task from beginning to end.  This is a good rule to apply to sizeable tasks.

The zero to 100% rule is what I use for progress in simple tasks I keep in my day planning.  Either it’s done or it’s not.  For example, either I’ve made that call I needed to put in to a construction manager about a particular topic, or I haven’t done it yet.

The 50/50 rule is a good one for medium sized tasks that might span a few days, provided that it really is in progress